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Abstract 


This document defines a mechanism for backhauling Digital Private 
Network Signaling System 1 (DPNSS 1) and Digital Access Signaling 
System 2 (DASS 2) messages over IP by extending the ISDN User 
Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, 
specified in ND1301:2001/03 (formerly BINR 188), is used to 
interconnect Private Branch Exchanges (PBX) in a private network. 
DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. 
This document aims to become an Appendix to IUA and to be the base 
for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. 
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1. Introduction 


This document describes a method of implementing Digital Private 
Network Signaling System 1 (DPNSS 1) [2] (henceforth referred to as 
just DPNSS) and Digital Access Signaling System 2 (DASS 2) [3] 
backhaul messaging over IP using a modified version of the ISDN User 
Adaptation Protocol (IUAP) [1]. The DPNSS/DASS 2 User Adaptation 
(DUA) builds on top of IUA by defining the necessary extensions to 
IUA for a DPNSS/DASS2 implementation. 


1.1. Scope 
There is a need for Switched Circuit Network (SCN) signaling protocol 
delivery from a DPNSS Signaling Gateway (SG) to a Media Gateway 
Controller (MGC). The delivery mechanism should support the 


following protocols: 


- DPNSS (Digital Private Network Signaling System) [2] 
- DASS 2 (Digital Access Signaling System Number 2) [3] 
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Unless specifically mentioned, the details in this document are 
applicable to both DPNSS and DASS 2. 


1.2. Terminology 


Data channel (D-channel) - A 64 kbit/s time slot that functions as a 
common signaling channel on a 2048 kbits/s interface or a 1544 
kbits/s interface that is provisioned to carry DPNSS signaling. 


DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 kbits/s 
interface or Time slots 1 to 23 on a 1544 kbits/s interface are 
termed as DPNSS channels. These are the traffic channels that carry 
voice or data traffic. 


- DPNSS supports 60 Channels (30 Real and 30 Virtual) 
- DASS2 supports 30 Channels (All Real) 


Data Link Connection(DLC) - A DLC is the level 2 process that 
controls the transfer of level 3 messages on behalf of one DPNSS 
channel. A DLC uniquely identifies one DPNSS channel. 


- DPNSS supports 60 DLCs (30 Real and 30 Virtual) 
- DASSII supports 30 DLCs (All Real) 


DPNSS Link - A logical collection of the D-channel and the 
associated DPNSS channels in a 2048 kbits/s interface or a 1544 


kbits/s interface is called a "DPNSS Link". 


Real channel - A signalling channel with an associated traffic 
channel (TS). 


Virtual channel - A signalling channel with no associated traffic 


channel. 
NT1 - The DPNSS minimum retransmission period. 
NT2 - The DPNSS minimum post retransmission acknowledgement delay. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [5]. 
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1.3. DPNSS Overview 


DPNSS is an industry standard interface (ref. ND1301:2001/03) [2], 
which is defined between a PBX and an Access Network (AN). DPNSS 
extends facilities that are normally only available between 
extensions on a single PBX to all extensions on PBXs that are 
connected in a private network. DPNSS was originally derived from 
BT’s Digital Access Signaling System I (DASS I), and was enhanced 
where necessary to meet the private network requirements. Some of 
these enhancements were incorporated in DASS 2 [3]. DPNSS uses a 
2048 kbits/s or 1544 kbits/s Digital Transmission System Interface, 
as shown in Figure 1 below. 


E o-==0 

| | 2048 kbits/s | | ------- /\ 

| PBX | 1544 kbits/s AN | 

| eee | o--o 

| | | |------- AN 
Figure 1 


Channel 16 is on a 2048 kbits/s (El) interface and channel 24 is on a 
1544 kbits/s (T1) interface and is reserved for data communication 


between LE and AN. The channels reserved for data are Called "Data 
Channels" or "D-Channels." 


The D-Channels are the physical media used to exchange data between 
the DPNSS protocol peer entities. A logical collection of the 
D-channel and the associated DPNSS channels is called a "DPNSS Link". 
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1.4. Proposed DPNSS Backhaul Architecture 
KKKKKK DPNSS KKKKKK IP KKKKKKK 
*PBX *--------------- * SG *-------------- * MGC * 
KKKKKK KKKKKK KKKKKKK 
+----- + Yoo + 
|DPNSS | (NIF) |DPNSS | 
TES, | | 13 | 
+----- + +---------- + +----- + 
| |_| Dual | Dua | 
|DPNSS | | DPNSS+----+ +----- + 
(ES! | 12 |scTP| |SCTP | 
| | | +----+ +----—- + 
| | | | IP + | īp | 
Yoo + Yoo +o---+ Yoo + 
NIF - Nodal Interworking function 
SCTP - Stream Control Transmission Protocol 
DUA - DPNSS User Adaptation Layer Protocol 


2. Changes from IUA 


This section outlines the differences between DUA and IUA. 


2.1. New Message Class for DUA 


The DPNSS/DASS2 Layer 2 to Layer 3 primitives 


[2] [3] need to be 


identifiable from IUA boundary primitive transport messages and the 


boundary primitive transport messages of other IUA extensions 


V5 or GR-303). Therefore, 
class parameter for DUA messages. 


For all DPNSS/DASS2 interface boundary primitives, 


Class is introduced: 


13 
(DPTM) 


Similar to IUA, 


(Eo 


it is necessary to use a different message 


a new Message 


DPNSS/DASS2 Boundary Primitives Transport Messages 


other valid message classes for DUA are: 


0 Management (MGMT) Message 
3 ASP State Maintenance (ASPSM) Messages 
4 ASP Traffic Maintenance (ASPTM) Messages 
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2.2. Message Header 


The IUA Message Header [1] MUST be used with the DPTM messages, but 
the DLCI field in the DLCI parameter is formatted differently. 
Figure 2 below shows the IUA Message Header with integer-based 
Interface Identifier. 


0 1 2 3 
01,2 3) AD BO OTs 223) A516 MIO A 08 AS do OBO Oo 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tag (0x1) | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Interface Identifier (integer) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tag (0x5) | Length=8 | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
DLCI | Spare | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + —+—+—+ 


Figure 2 IUA Message Header (integer-based Interface Identifier) 


In DUA, the DLCI field has a different format, in accordance with the 
ND1301:2001/03 (formerly BINR 188) [2]. 


0 1 

01.23 4-5: 0:78:90: 1.2304, :5 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved |v|0|Channel No. |1| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Reserved: 7 bits 
Should be set to all '0's and ignored by the receiver. 
V-bit: 1 bit 
The V-bit is used to determine if the message is for a particular 


DLC or if it is applicable for all the DLCs in the carrier. The 
possible values of the V-bit are listed below: 


Value Description 
0 Action is to be performed on all DLCs; 
Channel number parameter is ignored. 
1 Action is to be performed on a single 


DLC specified by channel number. 
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This V-bit value is used only by the Establish and Release 
messages. Data messages should ignore this value. This indicator 
is provided so that a single command can be issued to establish or 
release all the DLCs in one DPNSS Link. 


For Channel Number (Channel No.), the valid values are 0 to 63 for 
DPNSS and 0 to 31 for DASS 2. This is because DASS 2 does not 
support virtual DLCs and, hence, has only 32 DLCs. 


2.3. Unit Data Message 


DPNSS layer 2 does not have a unit data primitive and, hence, the 
Unit Data Messages (Request, Indication) are invalid for a DUA 
application. The Data Request and Indication messages (message types 
1 and 2, respectively) will be used with DUA. 


2.4. DLC Status Message 


For DUA, a new message is necessary to carry the status of the DLCs. 
This message will be a Management message (i.e., its message class 


will be a value of 0 for Management). The following message types 
will be used for these messages: 


5 DLC Status Request 
6 DLC Status Confirm 
7 DLC Status Indication 


The DLC Status messages are exchanged between DUA layer peers to 
request, confirm, and indicate the status of the DLCs. The DLC 
Status messages contain the common message header, followed by IUA 
message header, as described in section 2.2. 
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In addition, the DLC Status Confirm and Indication messages will 
contain the new parameter, called the DLC Status parameter. This 
parameter will have the following format for an El interface: 


0 1 2 3 
O-1 23.4.5 6 7 8 9-0-1 °2.3 4°5.6 7.89 0 123405306 789.01 


tata tata tata ta tartar ta tata tata tata ta tata ++ +++ +++ +++ +++ 
| Tag (0x12) | Length | 
tata tata tata tate tata ta tata + d+ + + d+ +++ +++ +++ +++ +++ 
| NA| D1| D2| D3| D4] D5| D6| D7| D8] D9|D10|D11|D12|D13|D14|D15] 
tata A tata tata ta + ta tata ta tata + d+ + ++ +++ +++ +++ +++ 
| NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|p26|D27|D28|D29|D30|D31 | 
tata tata tata tata tata ta tata ta tata + tata ++ +++ +++ +++ +++ 
| NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|p42|D43|D44|D45|p46|D47| 
tata tata tata tata tata tae tata tata + + d+ + ++ +++ +++ +++ +++ 
| NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|pD59|D60|D61|D62|D63 | 
tata tata tar + ta tata ta tata ta tata ta tata ++ +++ +++ +++ +++ 


NA stands for Not Applicable. DO and D16 are not applicable for an 
El interface because timeslot 0 is used for El framing and 
synchronization bits and timeslot 16 is used for signaling. For 
DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual) 
and in case of DASS2 there would be a total of 30 DLCs (no virtuals). 


This parameter will have the following format for a Tl interface: 


0 1 2 3 
Onde 2349. 76 BIZ A AA G20 N 23 6: ST 89 Oe: 


tata tata tata tata tata ta tata ta tata + d+ + ++ +++ +++ +++ +++ 
| Tag (0x12) | Length | 
tata tata ta e + tata ta tata tata tata + d+ + ++ +++ +++ +++ +++ 
| Do| D1| D2| D3| D4] D5| D6| D7| D8] D9|D10|D11|D12|D13|D14|D15] 
tata t ata taeda tata tata ta tata tata + + d+ + ++ +++ +++ +++ +++ 
|D16|D17|D18|D19|D20|pD21|D22| NA|D24|D25|p26|D27|D28|D29|D30|D31 | 
tata A AO A + tata ta ta tata ta tata ta tata ++ +++ +++ +++ +++ 
| NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|p42|D43|D44|D45|p46| NA] 
tata A tata tata taeda ta tata tata tata ++ + ++ +++ +++ +++ +++ 


D23 is not applicable for a Tl interface because timeslot 23 is used 
for signaling. For DPNSS, there would be a total of max 46 DLCs (23 
real + 23 virtual) and in case of DASS2 there would be a total of 23 
DLCs (no virtuals). 
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The parameter carries the status of DLCs using two bits for each DLC. 
The possible values for the two bits are shown below: 


Value Description 
00 Out Of Service 
01 Reset Attempted 
10 Reset Completed 
11 Information Transfer 


For DASS 2, the value 00 (Out Of Service) is invalid because the DASS 
2 DLC does not have this state. In addition, the Idle state is a 
transient state local to the DLC, therefore, a value is not allocated 
for it. 


For DASS 2, there are no virtual DLCs and, hence, information about 
only 32 DLCs need to be carried. Therefore, the status message will 
have a length of 12 for a DASS 2 DLC Status message. 

2.5. Management (MGMT) Messages 


Only the Notify and Error messages are valid for DUA. The TEI Status 
messages are not used. 


2.5.1. Error Message 


The ERR message is sent when an invalid value or unrecognized message 
is found in an incoming message. 


The Error Code parameter indicates the reason for the Error Message. 
These are the supported values in IUA. 


Invalid Version 0x01 
Invalid Interface Identifier 0x02 
Unsupported Message Class 0x03 
Unsupported Message Type 0x04 
Unsupported Traffic Handling Mode 0x05 
Unexpected Message 0x06 
Protocol Error 0x07 
Unsupported Interface Identifier Type 0x08 
Invalid Stream Identifier 0x09 
Unassigned TEI 0x0a 
Unrecognized SAPI 0x0b 
Invalid TEI, SAPI combination 0x0c 
Refused - Management Blocking 0x0d 
ASP Identifier Required 0x0e 
Invalid ASP Identifier Ox0f 
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In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are 
specific to ISDN. 


The following additional error codes are supported in DUA: 


Channel Number out of range Oxlc 
Channel Number not configured Oxld 


The "Channel Number out of range" error is sent if a message is 
received with a channel number greater than 63 for DPNSS or 31 for 
DASS 2. 


The "Channel Number not configured" error is sent if a message is 
received with a channel number that is not configured. 


3. IANA Considerations 


IANA has assigned a DUA value for the SCTP Payload Protocol 
Identifier field that is used in SCTP Payload Data chunks. The 
following value for the SCTP Payload Protocol Identifier field SHOULD 
be used for DUA: 


SCTP Payload Protocol ID = "10" 
4. Use of SCTP Payload Protocol ID 


As an option, the IUA value for SCTP Payload Protocol ID MAY also be 
used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS 
over the same SCTP association. However, use of separate SCTP 
Payload Protocol IDs (10 for DUA and 1 for IUA) is recommended as the 
primary option, even in scenarios where ISDN and DPNSS are backhauled 
over the same SCTP association. 


SCTP Payload Protocol ID of "10" SHOULD be used for DUA if only DPNSS 
is backhauled over an SCTP association (i.e., in scenarios where 
simultaneous backhauling of ISDN and DPNSS over the same association 
is NOT required). 


The SCTP Payload Protocol Identifier is included in each SCTP Data 
chunk, to indicate which protocol the SCTP is carrying. This Payload 
Protocol Identifier is not directly used by SCTP but MAY be used by 
certain network entities to identify the type of information being 
carried in a Data chunk. 
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5. Message Sequence in DUA 


An example of the message flows for establishing a data link ona 
signaling channel, passing PDUs and releasing a data link on a DPNSS 
channel is shown below. An active association between MGC and SG is 
established prior to the following message flows. 


5.1. Resetting of single DLC 


i) Successful 

PBX SG MGC 
KT SABMR <S 5 S4SS sso Est Req (Ind=1) 

UA ----------- > ESE Cfim .=======+>5=>= > (DLC in RC State) 


ii) Unsuccessful (Link Failure) 


PBX SG MGC 
Kass 23333 S SABMR LESS STRESS Est Req(Ind=1) 
Retransmissions over 
NT1 and NT2 expired 
Rel Ind ----------- > (DLC in RA state) 
(RELEASE OTHER, Ind=1) 


5.2. Resetting all DLCs in a Link 


PBX SG MGC 
(RSS SABMR (1) LFTSRAPESESE E Est Regq(Ind=0) 
GTA TARA SABMR (2) 

KSSsSSSS5S== SABMR (3) 

LESA SABMR (N) 

In each DLC either 

UA is received or 

NT1/NT2 is expired 
Est Cfm ----=-=====-=- > (Status of DLCs 
(Ind=0) are not updated) 

<= Sasa Status Req 
Status cfm ---------- > (Mark DLC status 
based on 


status bits) 
If one of more DLCs remains out-of-service after this procedure 


(e.g., due to layer 2 management), the MGC can either retry this DLC 
with an Est Req(Ind=1) indicating the specific DLC or with an 
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Est Req(Ind=0) and the SG will retry the appropriate DLC that is 
out-of-service. 


5.3. Information Transfer on a DLC 
PBX SG MGC 
SES SS UI (C) E Data Req 
UL(R)+=2===2===258 > Data. Ina. =====2=+5==% > 


5.4. Link Takedown (Single DLC) 


PBX SG MGC 
(For DPNSS, mark DLC as OOS) <= Rel Req 
(For DASSII, mark DLC as RA) (RELEASE MGMT, 
Ind=1) 
Rel Cfū '=========> > 
(Ind=1) 


5.5. Link Takedown (All DLCs) 


PBX SG MGC 
(For DPNSS, mark all DLCs as OOS) <-------- Rel Req 
(For DASSII, mark DLC as RA) (RELEASE MGMT, 
Ind=0) 
Rel. Cim ==-*====-== > 
(Ind=0) 


5.6. Getting Link Status 


PBX SG MGC 
<SSSsSsSses= Stat Req 

Stat Cfm ----------- > (Mark DLC status 
based on 


status bits) 


5.7. Error Conditions 
PBX SG MGC 
Invalid Message <----------- Est /Rel/Data/- 
Stat Req 
Error Ind- (=+=95+==3== > 


(Error Code) 
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6. Security Considerations 
The security considerations for the ISDN User Adaptation Protocol 


(IUAP) [1] (Section 6) and the security considerations for SIGTRAN 
Protocols document [4] apply to this document as well. 
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